IBIS Macromodel Task Group Meeting date: 26 March 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Arpad to submit Rx_Receiver_Sensitivity BIRD draft_4 to the Open Forum. - Done (BIRD199). - Walter and Mike L. to draft an email response to the BIRD198 submitters. - Done (to be reviewed in this meeting). -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the March 12 meeting. Walter moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: Draft response to the authors of BIRD198: Walter reviewed the draft he and Mike L. prepared. He first reviewed three statements intended to describe our understanding of the intent of the BIRD. Statement 1: * The [PDN Model Mapping] defines a model between two pin names in the [Pin] section, but we believe the intent is to define a model connected between the power/ground rail signal networks associated with those pins. Arpad and Radek agreed this was their general interpretation of the intent. Bob noted that BIRD198 specifies connections between [Pin]s, but [Pin Mapping] can extend that to on-die bus label and signal names. Walter asked if we thought that was their intent. Bob noted that in examples the authors had included bus labels. Arpad noted that this BIRD could be analogous to the series model specified between pins with [Series Pin Mapping]. As he had noted in the previous meeting, pin names were used because that's all IBIS had at the time, but the implicit connection is actually on the pad side. He said this would apply to BIRD198 as well. If the pads implicitly referenced in BIRD198 were connected to anything else via bus labels, they would all be considered shorted together. Given this interpretation, Walter concluded the first statement of intent was incorrect, and he changed it to: * The [PDN Model Mapping] defines a model between two pin names in the [Pin] section, but we believe the intent is to define a model connected between the power/ground rail signal networks (signal_name or bus_label) associated with those pins. Statement 2: * We believe this model would be limited to on-die decoupling capacitance connected between rail signal names. Any decoupling capacitance between rail signals on the package (for example, package decoupling capacitors) would not be included in this model. That capacitance would have to be included in a package model. Walter said the intent of the statement is to ensure that this model is confined to on-die only effects. Any package effects must be in the package model. Based on the previous comments with regard to bus labels, this second statement was changed to (note the addition of "or rail bus_labels"): * We believe this model would be limited to on-die decoupling capacitance connected between rail signal names or rail bus_labels. Any decoupling capacitance between rail signals on the package (for example, package decoupling capacitors) would not be included in this model. That capacitance would have to be included in a package model. Statement 3: * We also believe that BIRD 198 implies that all of the on-die pads and on-die buffer connections to each rail supply voltage (signal name) are short- circuited, so that there is a direct connection, and no rail interconnect circuit elements, between the supply rail die pads and the buffer supply rails. This statement was intended to note that there is no on-die power distribution other than the decoupling caps defined in this BIRD's model. Arpad agreed. He noted that this proposal was written without consideration of the new BIRD189, and it likely is based on the legacy IBIS constructs in which buffer and die-pad locations are considered to be the same. Based on the previous bus label discussion, this statement was also amended to include bus_labels. Mike L. noted that we needed to be careful to refer to "rails" and say that they are identified bus labels. Walter agreed wordsmithing could be undertaken, and noted that he had used signal names and forgotten this would apply to bus labels too. Walter noted that he had some thoughts on a proposal for streamlining the syntax of the proposed BIRD, particularly for the parser. But after a brief discussion he and the group decided that we should not pursue that at all at this time. The primary goal for now is to investigate whether BIRD189 can provide an acceptable and more general solution to the problem addressed by BIRD198. We can worry about any possible refinements to BIRD198 later, if necessary. The email provided an example of a BIRD198 model implemented using BIRD189. It also provided several suggestions for addressing the shortcomings of BIRD189 in this scenario (corners, need for an additional file for the ISS model, etc.). Arpad suggested we keep it simple at this point, and not get involved in discussions about how we might address any issues BIRD189 has right now. We simply note the issue with respect to corners, and state that we could work on improving that support later, for example. Mike L. agreed. Bob noted that he didn't understand why one suggestion was for a hard coded "reserved" file name for this type of model. Walter noted that he was attempting to address the authors' concerns about additional complexity and needing to add extra files. If we had a reserved file with a given structure (their model), the parameters would simply be provided in the IBIS file, not an additional file. Radek noted that this was a valid point, if we are encouraging the authors to consider BIRD189 instead of their proposal, we should to have a way to define their model structure without the additional complications of an extra file. Bob noted that this would be falling back to the authors' proposal in the sense that you'd have a fixed simple topology. Bob noted that [Series Pin Mapping] and series models already provide a superset of this BIRD198 proposal. Everything in BIRD198 could be done with [Series Pin Mapping]. Mike L. noted that the authors wanted PDN_ in the name to make it clear that a PDN was involved. He noted that he and Walter had used PDN_ in all their BIRD189 example names for this reason. Randy noted that it might be hard for the parser to figure out if BIRD198 parameters collide with a BIRD189 model. Arpad noted that BIRD189 could define a package model, and then BIRD198 might be connecting pads, so this interaction could be tricky. Arpad proposed that we add an additional question to the email, what is the authors' intent for the interaction of this proposal with BIRD189? Walter added: * Was your intent for this proposed syntax to be used along with BIRD189 models or exclude using these models with BIRD189 models? Bob noted that we might want to reference slide 7 from Murata-san's DesignCon presentation. It states that another method for supporting die-caps using IBIS 7.0 will be investigated. We can state that we are attempting to help with the investigation. There are many advantages to BIRD189. Walter took the AR to send out the modified draft response to those in attendance, field any requested changes, and serve as master editor. - Michael M.: Motion to adjourn. - Mike L.: Second. - Arpad: Thank you all for joining. AR: Walter to send out the modified draft response for further review by those in attendance. ------------- Next meeting: 02 April 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives